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Why is Sims 2 Interesting? 


°o Massive amounts of content 
¢ Animation heavy 
¢ Sound heavy 
° Massive amounts of people! 
° Graphics: “The users design the levels” 


°o Visual game scripting language (Edith) drives 
much of gameplay. 


Long Project 


o Started in late 2000 


© Mostly a small research team (5—20 people) for a 
few years 


0 In full production for 2+ years 
0 250+ people at the end 
°0 Slipped! From January ‘04 to September ‘04 


o Extended crunch 


Stats: Highlights 


0 4CDs 

0 11,000 shipped animations 

o 1.1 million lines of code 

0 2,400 UI images 

© | GB sound data 

© & GB development build footprint 
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0 11,775 shipped animations 

o 4,500 models, 8,100 textures 

0 50,000 lines of effect scripts: 2000 total effects 
0 D7 Movies 


© 3.5GB of source data for Sims, 630 MB for 
objects 


°o 2,400 UI images 

0 240 UI scripts 

0 942 catalog items 

o 2] language string packages 


o 92 cursors 


Art Staffing (at) 


0 About 35 artists at peak 
¢ 17 Animators (12-14 by ship) 
¢ 13-14 Modellers 
¢ 3 Technical Artists 
¢ 2-3 UI Artists 
¢ 2-4 Effects Artists 


o Some overlap 


© Photoshop, Maya-based from the beginning 


© Brought over all Sims I animations, targetting 
new Skeleton 


o Used none! 
© MEL front end for material system 


¢ In general, MEL very useful for adding UI, 
absorbing pipeline logic 


Art Pipeline (at) 


0 Photoshop -> TGA -> Asset Compiler (Go2SCO) 
¢ added direct PSD support: useful because of layers 

0 Maya -> EA3 -> Asset Compiler 

o Artists check in source files to perforce 


¢ Build machine runs them through pipeline, sends 
error summary to submitter (a few minutes) 


¢ Also updates animation/models report: web-based 
view of every asset and its stats 


The Skeleton (at) 


0 27 facial targets 
packed into 4 delta 
streams 


0 64 weighted bones 


o 116 bones total, 
including grips and 
other registration 
points 


o Skeleton not locked 


Modelling (at) 


o Lucky enough to have continuity from Sims 1x 


o Sims: maintained single texture sheet approach, 
but composited tops/bottoms together 


o Artists weren't given a poly budget: batch count 
is all 


o Ditto textures(!) 


o Contracted out object LODs: tried to always 
have a single-material LOD 


Modelling Feedback @ 


0 Had Texel Density visualisation mode, for 
identifying “hot” objects where texels were 
wasted 


o Had an animated model/texture map display 


© Could switch between four different shader paths 
in viewer to verify lighting was correct. 


o Art produced original lighting design. Had a 
TDD, and was prototyped. 


°o Two dedicated people tuning lighting system via 
script system 


« System evolved according to art, especially early on 
¢ Artificial contrast boosters, emphasis on gradients 


¢ Downside: a large number of knobs, confusing for 
someone new. 


Level of Detail (at) 


°o Static LOD 
o Never formally spec’d 


o All Sims had one LOD (two models total), about 
50% of objects had at least one LOD. 


© Initial overly-ambitious plans left us scrambling 
at the end 


0 Dropped dynamic LOD switching due to visual 
glitches 


Sound (at) 


0 143 MP3s 

© 43,000 spx vox samples! 

°o 2,600 footsteps alone + 7,500 ambient samples 
0 16,000 unique sound events 

o Fully half our data footprint: 1 GB 


© 35,000 sound resources loaded going into the 
neighbourhood 


°o Difficult! 
¢ Need to improve on one of the best games of all time 
¢ Attract new players 
¢ Without putting off previous players 

o Diverse audience 


« Past surveys have shown even split between at least 
four different styles of play 


o Aiming for 90+ metacritic rating 
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It Gets Worse Don. 


o Big pressure from EA! Constant demo pressure 
worked against design gelling 


o How much new stuff is enough? 


o The ‘spiralling delay’ trap—longer it takes, better 
it has to be 


o Some of earliest ideas cannibalized for 1x 
expansions, plus people who originated them 


o Changed one of the lead designers in 200 
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New Gameplay Den. 


°o Movies 

o Aging! 

0 Generations and Genetics! 

o Big Life Moments & Cinematics 
o Aspirations? 


o Wants & Fears?! 


o Done. Phew. 
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o After slip, needed extremely tight control to 
ensure we hit our mark: 


¢ Change review—any new design feature thoroughly 
vetted, most dropped 


¢ Feature producers dedicated to seeing a particular 
feature completed 


¢ Big new areas were tightly compartmentalized 


¢ E.g., wants and fears: two engineers working closely 
with OE and design/production 
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It shipped! Den, 


0 The delay was crucial 


o Finally got enough compelling new gameplay to 
bring back previous buyers. 


o Finished (most of) engineering 
°o I million units sold in 10 days 


o Sales in Europe > North America 


o Lesson: Never give up! 
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But at a Cost Don. 


o Constant design change was a negative for the 
rest of the team 


0 Most of Maxis moved to EARS in early 2004 
¢ Corresponding loss of studio identity 
© Various talented people burnt out, some leaving 


¢ Worry that will impact future hiring prospects 


o Big incentive to learn how to manage “big 
product” process better! 
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Object Engineering © 


0 18-19 OEs 
°o 1,700 game objects! 
o Simulator and object scripts drive all gameplay 


© Mostly nice coupling of logic and associated 
game object 


o Simulator closely coupled with C++ primitives 


o Sometimes mismatch between complexity of C++ 
primitives and simplicity of Edith 
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Artist/OE Interaction © 


o Essentially, artists provided source animation, 
OEs supplied blending (not ideal) 


0 A big problem synchronising 


0 Skunkworks project produced “Clockwork”, 
which allowed easy previewing of animations 
and associated effects 


© OEs could use this to explore art assets when 
writing scripts, rather than bugging artists 
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o Less interesting than you think! 

© Actually, visual scripting doesn’t work very well 
¢ No revision history 
¢ No good search/replace 
¢ Single edit: once person at once 


¢ Difficult for script sweeps 


0 At the end of the project, all OEs wanted to move 
away from it 


29 


o Positives: having a good debugger is crucial 


o After SC4 and Sims 2, studio consensus is that 
Edith has more cons than pros 


°o The future: Lua 
¢ Used on SC4 with some success 


¢ In use on various next gen titles 


¢ But debugger a work in progress 
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Engineering ng. 


o Around 28 engineers at peak. Very roughly: 
¢ 4 Simulation 
© SUI 
¢ 4 Graphics only, 7 Graphics/Gameplay/World 
¢ 4 General 
¢ 2 Animation 


¢ I Audio 
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Stats: Engineering ©@® 


°o 1./ million non-comment, non-blank lines of code 
¢ 325,000: framework code shared across the studio 
¢ &0,000 graphics engine, 45,000 animation 
¢ 110,000: Shared between app/tools 


¢ 540,000: game-specific. Gameplay, UI, world 
construction, lighting... 


0 17,000 lines of material/shader scripts 
0 1,000+ lines camera/catalog/lighting 
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Building Stuff @ 


o Dedicated engineer: The World DB 

¢ Terrain, all house geometry, object location 
o Bridge between gameplay and engine 
o Kept tile-based system 

¢ Mostly for Ul/gameplay reasons 


¢ Actual world DB code mostly only cared about walls 
and rooms as quad-edge data structure 


¢ But this wound up being overly general 
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°0 Achilles heel of Sims 1 
¢ Painful: “Party syndrome” 

0 Contracted company to write a replacement 
¢ But, slow, memory hungry, not that good 
¢ Integral part of gameplay: needs tteration 


o Instead, dedicated an engineer to the system 


© Worked with OEs to solve most problems 
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o Standard, quad-tree based 
o Smarts improved, higher tile granularity 
© Tied to simulator: gardener, ghost, fireman 
o “Step over” 
¢ Essential for all those messes on the floor 


o “Side stepping” 


¢ Two Sims can pass each other in a narrow space 
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Animation Eng. 


0 Full multi-channel blending, two-bone IK 
0 Look at 
¢ Sims can glance at each other on room entry etc. 
0 Hair bounce 
o Standard Reach 


¢ Used for Sims to hit various targets 


o Cinematics 
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Effects System Eng. 


o Script-based system 


« Effects composed from “components” : particle 
systems, decals, sounds, models... 


¢ Hierarchical: can nest effects, “meta” particles 
¢ Random walks, particle stretch, attractors, colliders 


o Key: all scripts are hot-loaded, rapid iteration 


0 Handles UI too: thought balloons, most build 
mode tools 
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Example: Fishies ©®@ 


© The fish tank is all an effect 


¢ Fish are model particles with random walks bounded 
by colliders 


¢ Game can kick an effect between states 


¢ When fish die, wind force floats them upwards until 
they hit tank’s “top” collider 


¢ On collision, die and spawn dead fish model 


¢ Can also switch to state with food attractor 
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Neighbourhood ng. 


o Lots were imposterized on lot exit 


¢ All walls and floors captured into small set of texture 
pages via render targets 


¢ Object substitution for “important” objects 
o SimCity tie-in with terrain generation 


¢ Roads and trees imported directly 


¢ Everything else is effects 


« User can even place these 
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Lighting Systm ©@ 


o Lighting was room based 


¢ Each room had a light rig generated for it 
automatically 


¢ User-placed lights only affected objects in that room 
¢ Portals transmitted light between rooms 
o Time of day states, smooth transitions 


¢ But, states cut to day/night only. Smooth object light 
transitions killed due to engine issues. 
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Lighting ng. 


Portals Room Light Rig 
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Lighting ng. 


o Exterior lighting predefined 


© Objects and portals have various light 
multipliers depending on inside/outside 


¢ Falloff, cutoff, intensity, directionality, etc. 
¢ Had 2x “over-bright” lighting 


°o Floor and walls were light mapped 


¢ 2D Diffusion algorithm used for “faux” radiosity 
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Shadows Eng. 


o Terrain and house: height map shadows 

¢ Fast CPU-side algorithm 

¢ Baked directly into light maps 

¢ Allowed simple object-as-a-whole shadowing 
°0 “Cookie-cutter” projective shadows 


« Dynamic only for Sims, and some animating objects 


¢ Static for objects, updated in a staggered manner 
with a frame budget. 
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Shadows Eng. 


o Tricks 
¢ Blur and threshold, so could use pretty low-res maps 
¢ Share for identical objects with same rotation 
« Many shadows packed into a single render target 


o Indoor: GUOBS 


¢ Prebaked “straight down + ambient” shadows 


¢ Contact shadows, e.g. for wall objects 
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Scene Graph ng. 


0 Graphics engine was a fully general scene graph 


o All model, camera, and hardware light 
manipulations were carried out via graph node 
manipulations 


o A model was just a (tagged) subbranch of the 
scene 


¢ Could be many nodes: hundreds for a Sim 


¢ Many operations involved traversing a branch 
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Graphics Performance ® 


0 Many objects in a house 


© Terrain and house split into sectors for culling 
and dynamic lighting 


o As batch count hits the thousands, start to get 
CPU hit 


¢ Generic scene-graph-based graphics engine rebuilt 
display list every frame: CPU hit per part 


¢ DIP cost becomes prohibitive 
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Solution: Dirty Rects ® 


ig Sims2Load: Done 


Dirty Rects ng. 


o No, really. (And we thought SC4 was it.) 


© Initial “hold” scheme gradually morphed into an 
SC4-style static/dynamic layer model 


o Cause of some of our card compatibility 
problems. (Copying depth surfaces is tricky) 


o Lighting system required complicated last-minute 
update to generate dirtied areas: tile-based 


o Shadows, particle systems, etc. retrofitted 
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Target Platforms ©@ 


°o Order of magnitude differences between our low 
end and high end in many categories 


« Memory, VRAM, Card capabilities 


o Had to support non-T&L commodity Intel 
hardware 


0 Pixomatic fallback for unsupported cards 


o Biggest target was DX7-level cards 
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Game Configuration ©® 


° Complicated! 


o Used SC4-derived configuration system, but with 
more logic in the scripts 


o Cards are identified from vendor ID, plus driver 
version 


o Special cases as appropriate 


0 Usual headache estimating texture memory 


o Relying on caps bits does not work at all 
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© A lot of STL 
¢ Not always efficient, but golden for leak prevention 
o Ref counting and interfaces: AutoRefCount<> 
o Custom allocators 
¢ Per-object pools: very low allocate/dealloc overhead 


¢ A refined cross-platform evolution of dlmalloc 


o Per-class leak detectors 
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Leak Observations ® 


0 Ranking leak causes: 
¢ By far, manual news/deletes 
¢ Then manual refcounting. 


¢ Finally, ref-count loops due to improper Init()/ 
Shutdown(). 


o Biggest finalling leak: 
¢ SC4: Lua! 


¢ Sims 2: Logging system! 
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Virtual Memory ©@ 


© Traditionally the crutch of PC games 


o Free lunch is running out: Virtual Memory 
fragmentation and exhaustion rearing its head 


0 DLLs carve off large amounts of address space 
0 Operating system takes ever larger amounts 


°o Memory fragmentation can bloat application’s 
footprint 
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Blue: reserved, white: committed, 
green: exe/dll, red: mmap 
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Resource Management Eng. 


0 Key based: originally 96 bit keys 
¢ Resource UID/Group UID/Instance UID triplet 
o Unpacked form: resource is a file 


0 Packed form: package compiler mapped resource 
directory hierarchy into a set of large files 


© Worked well for previous large-content games 
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o Overused resources. Some simulator resources 
were tiny: 12 bytes each! 


© Models stored as scene graph nodes etc.: a single 
model could easily become 30-50 resources 


o 15,000 models/anims -> 100,000+ resources 


o Key collision: Sims 2 engine allocated resource/ 
group via class UIDs, and hashed string file 
names into instance ID. A hash is not a UID. 
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o0 What about custom content? 
¢ Player A loads skins created by players B & C 
¢ Naming doesn’t work: they both called it “Bob” 


o Large number of files meant the development 
build’s load time became prohibitively slow 


¢ Load logs were main tool for identifying problem 
areas: simple time-stamped checkpoints. 


« Added development build caches 
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Solutions Eng. 


o In the end, just extended instance ID to 64 bits 


¢ Case study in making risky changes late in 
development. (Happened after BodyShop ship) 


¢ Work was done in a sandbox separate from main 
development line, and tested thoroughly before merge 


o For custom content, relied on trusty 128-bit GUID 


¢ Alternative: use hashing, deal with collisions. But 
gets complicated fast. Simple brute force solution is 
preferable. 
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Configuration Management om 


0 Soaked up a lot of effort: 6-8 engineers 
o Testing 
¢ Drove the game through the command console 


¢ Tests could then be scripted using a simple command 
script. 255+ test scripts! 


¢ Highly successful approach, used on a number of 
previous products 


o Simple “sniff” test required before all check-ins. 
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Configuration Management 


0 Adopted “DevTrack” bug database during SC4 
¢ Awful—slow and buggy, but stuck with it, improved 
¢ Interaction with testers limited to this 
¢ Testers: hundreds 

° “Robbie” tool for rolling out builds 
¢ Builds copied incrementally. Could be slow 


¢ No rollback facility! 


a Ctark traroec ta wah cito 
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Source Control om 
ee | es 


Y Y 
ae els 


Testing Testing 


°0 Two code lines, builds from both were tested 


o Pre-checkin code reviews tried early and 
abandoned. Reinstated during finalling. 
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Lessons Learnt 


What Went Right 


°o We could always hit art lock. The explosion in art 
assets required turned out to be the least of our 
scaling problems 


« Learn from the animation industry—they’ve been 
doing this for a while! 


¢ Hire from the animation industry. As content gets 
larger, processes get ever more similar 
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o Need stable design! 
¢ Too many cooks syndrome 
¢ Need concept art, templates, established look 


o Modellers <-> animators <-> OEs sit closer 
together 


© More consultation from engineering. Tighter 
turnaround for code changes 


© Lack of technical art types hurt 
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Design Risk 


°o Well known: cost of a bug increases the later you 
catch it 


°o Corollary: cost of design changes increases 
exponentially the later they occur 


0 But Sims 2 couldn't afford to ship without getting 
the design right 


0 Caught between a rock and a hard place, but 
need to avoid this in future. 
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Engineering Lessons 


o Concentrate on the game, not the engine 


0 Beware of cathedral building: Get systems in 
place early 


o Scene graph belongs in the pipeline 
o Never ignore value of shipping-hardened code 


0 Don’t contract out core gameplay components 


° More urgency! 


67 


What Went Wrong 


Transporter Accident #231 
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Over-Engineering 


o Some areas of the code base were massively 
overengineered 


¢ E.g., pixel formats were represented by a number of 
COM interfaces. 2200+ lines of code in all. 


0 Bubble-wrap syndrome 
¢ Feels like it should be simpler to do X! 


o Prefer toolkit to one-stop-shop 


¢ Too generic = too hard to change and iterat 
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Template Meta Programming 


o Sims 2 Math/Vector library used this 


¢ Performance improvement was never actually 
measured by writer. Turned out to be a slight 
decrease in performance in optimized release build 


o Negatives: 
« Impact on debug speed was horrific (75% hit) 
¢ Very difficult to read 


¢ Very difficult to debug: deep stack traces 
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API Churn 


© Lock low level parts of the game well before the 
final phase of development! 


0 API churn in low level systems is unacceptable 


« Engineers can't keep track of current feature set, or 
propagate knowledge about that feature set 


¢ Introduction of subtle bugs 


¢ Can't build on sand 
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© Main problem of engineering team: lack of 
productivity for some core tasks 


¢ Spent weeks or months trying to do some things “the 
right way” 
¢ Planned overly-ambitious systems, ran out of time to 


implement them: Cathedral building 


o But... what’s wrong with taking time to build the 
cleanest and most generic system possible? 
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Opportunity Cost Examples 


o We have nice normal maps. They only show up 
on a 128MB+ card 


°o Static LODs: picked depending on machine type, 
don't change in the lot 


°0 Shader path that consumed most dev. time (DXS8) 
was dropped in last weeks 


o Hacky game-side culling. (Objects hidden 
manually by world DB code.) 
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Going Forward 


o How are we applying these lessons? 


o Real Estate has location, we have... 
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Preproduction 


0 One of the biggest learning experiences of Sims 
2: this is crucial for large projects 


¢ Explore and solidify design with prototyping 
«¢ Assemble look bibles, concept art, storyboards 
« Explore any new technologies necessary 


o Then, slowly ramp up to full production 


¢ Must be sure to have all ducks in a row, and only add 
people when underlying systems are ready 
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Why not before? 


o Sims 2 was small, “under the radar” research 
team for a few years 


0 Flipped directly to production when studio focus 
changed 


© Maxis did not have a lot of experience with 
preproduction concept 


o Deadlines and team sizes hadn't been such that it 
was crucial 
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Communication 


o Return of the King used “pod” style of working 
¢ Small, tightly coupled, interdisciplinary groups 


© Model has worked well at Maxis in an ad hoc 
way, now being adopted more formally 


o Gaal is to increase communication bandwidth 
where it matters, 


o Also: flatten hierarchy 
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Example: Pools 


i $ 
ie VersI 4 
pO A 


Wier é 
alas : S$ 


°o Cut for original January deadline 
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Swimming Pools 


0 Skunkworks team got together to save them: 
« Simple set of animations 
¢ Changes to router and world to treat as special room 
¢ Basic interacting water surface with caustics 


0 All put together in only a few weeks outside 
normal tasks 


o Slip allowed more animations and lighting 
refinement 
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Art 


0 Already implementing pre-production in a 
number of development titles 


¢ Successfully using concept artist to rapidly explore 
both look and design space 


© Work to have content validation tools working in 
place before production 


0 Replicate Sims 2 auto-content-build and content 
browser on other projects 
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o It's all about managing complexity 


o Prefer smaller, tighter teams focused on 
particular features 


o Prefer rapid development when the new system is 
an unknown 
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Technology 


o Transitioning to Renderware 
¢ Toolkit approach to graphics API 

o Adopting effects system as shared technology 
¢ Also being used for rapid prototyping 

0 Switching to text-based scripting 


o Better and more integrated game object/asset 
databases 


o Continue to evolve scrinted testine 
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